AIAA 2003-4603 


COBRA System Engineering Processes to 
Achieve SLI Strategic Goals 

Richard O. Ballard * 

Space Transportation Directorate 
NASA Marshall Space Flight Center, AL 


The COBRA Prototype Main Engine Development 
Project was an endeavor conducted as a joint 
venture between Pratt & Whitney and Aerojet to 
conduct risk reduction in LOX/LH2 main engine 
technology for the NASA Space Launch Initiative 
(SLI). During the seventeen months of the project 
(April 2001 to September 2002), approximately 
seventy reviews were conducted, beginning with the 
Engine Systems Requirements Review (SRR) and 
ending with the Engine Systems Interim Design 
Review (IDR). This paper discusses some of the 
system engineering practices used to support the 
reviews and the overall engine development effort. 

1. Introduction 

1.1 The Space Launch Initiative 

The NASA SLI program was initiated under NRA8-30 
to begin development of a space launch system that 
would be significantly safer and more economical to 
operate than current launch systems. SLI was identified 
as part of the Integrated Space Transportation Plan 
(ISTP) and followed on the NRA8-27 study to define 
an optimal roadmap that would produce a 2"^^- 
Generation Reusable Launch Vehicle (2GRLV). The 
objective of the NRA8-27 study was to identify risk 
reduction areas and were applicable to several 2GRLV 
architectures by performing cycle analyses and trade 
studies on applicable propulsion systems. Risk 
reduction activities were then identified to mature the 
technologies and cycles to production status. Other 
elements of the ISTP identified at that time included 
upgrades for safety of NASA’s 1^^-generation RLV, the 
space shuttle, and developing technologies for third and 
fourth generation transportation systems. 

The 2GRLV program was to build on NASA’s then- 
current programs (e.g., X-33, X-34 and X-37) — testing 
new materials, structures, propulsion, computers and 
other technologies needed to meet the program’s goal 
of significantly increasing safety to a 1 in 10,000 
chance of loss of life and reducing payload launch costs 
from $ 1 0,000 per pound today to $ 1 ,000 per pound. 



The scope of NRA8-30 covered more than just the 
propulsion facet of space transportation. The ten 
technology areas (TAs) worked on all elements of the 
next manned space launch infrastructure. In addition, 
NRA8-30 was separated into multiple cycles and 
phases to permit management flexibility. Cycle- 1 
would focus on initial prototype development and risk 
reduction, with Cycle-2 culminating in the 
demonstration by test of the prototype engine. Phase-2 
of the SLI program would build on the foundation laid 
by the prototype engine project by the design, 
development, test, and deployment of the human-rated 
full-scale development (FSD) flight engine. 

Under Cycle- 1 of the 2GRLV program, two prototype 
LOX/LH2 main engines were selected for development 
to reduce technical risks; the COBRA engine by the 
Joint Venture (JV) of Pratt & Whitney (P&W) and 
Aerojet, and the RS-83 by Rocketdyne. 
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1.2 The COBRA Engine 

The Co-Optimized Booster for Reusable Applicati^] 
(COBRA) engine is a reusable, LOX/LH2 600K c 
engine system utilizing the Single Burner Fuel-! 
Staged Combustion (SBFRSC) power cycle set up 
around the existing SSME ATD high pressure 
turbomachinery. The SBFRSC cycle reduces the 
potential for oxygen-rich failure modes inherent in 
dual-burner cycle, thus increasing engine reliabilit] r 
safety. The hot combustion gases from the prebun lei 
drive both the hydrogen and LOX turbines in 
before entering main chamber. This design decreafei 
the turbine temperature, increasing engine life 
expectancy. In addition, the use of a single “liquidj* 
liquid” prebumer means that the high transient turl 
temperatures seen in the dual-burner staged combu^ti 
cycle are eliminated. Additionally, the fuel and h 
turbine temperatures are essentially “averaged” in 
single-burner system, allowing the peak temperai 
the system to stay at a more betiign level. The Rusfei 
RD-0120 engine also uses this cycle, though with ^ 
integrated single-shaft LOX and fuel turbopump. 
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a Technical Performance Measurement (TPM) process. 
TPMs are product metrics used in the prototype engine 
project to detail the development path and track the 
progress made toward the FSD goals. 

The prototype engine components would be pf 
sufficient similarity with the FSD engine to * 
demonstrate functional performance that encompasses 
the requirements (i.e., flows, temperatures, pressures, 
transients, self-induced environments, etc.) for the 
expected FSD engine. Prototype component^ and 
component test programs would be designed jo induce 
FSD engine expected loads in areas where tectoology 
readiness must be demonstrated. The prototype 
components would also be of sufficient fideli^ to 
demonstrate functional performance at a levei near the 
FSD engine target to allow validation of analytical 
design models in the range of expected FSD engine 
operation. If scaling of the prototype engine design to 
match actual FSD engine conditions is required 
following the prototype testing, the analyticalj models 
used would be sufficiently anchored to establish the 
expected trend beyond the prototype test poinfe. 
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The COBRA engine system was selected for 
development under the Cycle- 1 of the NRA8-30 Sll 
program under contract NAS8-0 1108. The genesiq of 
the COBRA engine system originated during the 
development of the P&W XLR129 engine for the 
USAF in the early 1970’s. The system utilized a 
integrated “powerduct” arrangement, with the sep; 
turbopumps mounted in a close-coupled configura^( 
with the single fuel-rich prebumer to a double- wai 
hot gas duct. The COBRA prototype engine was t( 
developed in a step-by-step building block approach 
that leveraged the heritage of the existing SSME AjTD 
turbomachinery and included extensive testing of 
subscale, subsystem and prototype hardware. 


1.3 Prototype vs. FSD 


One of the initial primary objectives of Cycle- 1 off 
NRA8-30 main propulsion (TA-8) effort was the 
development of a prototype engine system that “bujmed 
down” development risk and cleared the way for 
development of the FSD flight engine. In the abse^c 
of an actual vehicle to drive the FSD engine 
requirements, a set of prototype (i.e., Level-2) 
requirements was synthesized from the available 
vehicle architectures and released in the 2GRLV 
Propulsion System Requirements Document (PSRJf)) 
The JV then generated the system-level (Level-3) 
requirements from the PSRD and further decompoje 
requirements to the component level (Level-4) witf j 
emphasis on showing a path (i.e., with little or no 
development gaps) to the FSD engine. The key 
requirements were fiarther characterized and trackeii by 
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2. Systems Eneineering 

The development of an advanced propulsion iystem 
involves complex requirements, restrictive constraints, 
the use of sophisticated technologies, and the 
application of many diverse disciplines and personnel 
over an extended period of time. Systems engineering 
deals with the development, operation, and ejipenditure 
of such a system in an orchestrated manner by 
identifying and utilizing the interrelationship^ between 
elements of the system and the processes by \feth the 
system is developed and operated. The application of 
systems engineering processes is necessary for 
managing and controlling the development of a rocket 
engine propulsion system. It describes the process of 
defining and refining customer requirements ibto an 
integrated program and technical plan. Management of 
the systems engineering processes was detailed in the 
Systems Engineering Management Plan (SEMP), which 
also identified the organization, direction, and control 
mechanisms to insure that program safety, quality, cost, 
and schedule meet customer expectations. 

The JV established an Engine Systems Integration 
Team (ESIT) which operated in parallel to die 
Component Integrated Product Teams (CIPTs) and was 
responsible for system optimization and system trade 
studies. The ESIT consisted of different elements 
supporting the system engineering function: 

• Systems Design & Component Integration 
(SD&CI) 

• Propulsion Systems Analysis & Integration 
(PSA&I) 
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• Product Development & Validation (PD&V) 

• Reliability & Mission Assurance (R&MA) 

• Manufacturing Systems Engineering (MSE) 

2.1 Customer (Government^ Insieht 

The process of customer insight offers many means by 
which NASA was able to provide input and guidance to 
the contractor while remaining informed on the 
progress and current issues of the development effort. 
This would involve praise and criticism in equal 
measure, usually cast in both directions. Four levels of 
insight are currently used at NASA, with Level- 1 being 
the lowest level of government participation 
(effectively giving the contractor a bag of money and 
hoping an acceptable product is delivered at the end of 
the contract period), and Level-4 being the most 
intensive (the government conducts a similar effort in 
parallel to the contractor). For the COBRA project, 
NASA established Level-3 insight, which included: 

• regular involvement to identify and resolve issues, 

• review assumptions and findings, 

• comments to test plans and procedures, 

• support resolution of anomalies in test or analysis, 

• regular technical interchanges, 

• methodical reviews of process analyses and study, 

• independent analysis, 

• chairing of review boards in a formal fashion with 
data deliverables commensurate with formal 
hardware and software development approaches. 

2.1.1 Milestone Reviews 

One avenue for the provision of customer insight was 
the conduction of milestone reviews. The COBRA 
team set a very aggressive development pace in order to 


achieve the SLI schedule to demonstrate a Technology 
Readiness Level (TRL) of 6. In the space of 1 7 
months, the COBRA engine development team 
successfully conducted about 70 system-, subsystem- 
and con^nent-level reviews. These reviews included 
System Requirements Reviews (SRRs), Preliminary 
Design Reviews (PDRs), Interim Design Reviews 
(IDRs), Detailed Design Reviews (DDRs) and Critical 
Design Reviews (CDRs), In addition, there were 
numerous Technical Interchange Meetings (TIMs) 
conducted to discuss issues of a particular focus. In the 
course of the milestone reviews, approximately 525 
Review Item Discrepancies (RIDs) were initiated, 
dispositioned and closed. This number does not include 
the additional of action items and comments generated 
during the milestone reviews that were similarly acted 
on by the JV team. A summary of the different 
milestone reviews are shown below in Table 1 [^] 

Early in the project, it was quickly noted that the high 
number of reviews was producing a correspondingly 
large (and seemingly never-ending) number of RIDs. 
This was due to there being no separation of major 
issues fi*om trivial ones in the screening of RIDs. The 
growing problem was that each RID, whether it was 
critical or irrelevant, had to go through a lengthy 
process of initiating, screening, dispositioning, 
implementing, verifying and closing. The formal 
process of executing RIDs involved an exhaustive chain 
of signatures that had to be provided at each step in the 
process (Initiator -> Screening Team Lead -> 

Developer -> Review Team Lead -> Actionee -> 
Initiator -> RID Captain -> Lead Systems Engineer -> 
Project Manager). In addition, if there was a review 
preboard or board, this also required additional 
signatures fi-om the chairperson of those entities. 


Review 

SRR 

PDR 

IDR 

DDR 

CDR 

Design Complete (%) 

0 

50 

60 

70 

90+ 

Drawings Complete (%) 

0 

10 

15 

--35 

90+ 

Primary Review 
Objectives 

• Confirm that 
requirements and 
their allocations 
in the system spec 
are sufficient to 
meet project 
objectives 

• Demonstrate that 
preliminary 
designs meet 
system 

requirements with 
acceptable risk. 

• Identify all 
interfaces and 
verification 
methodologies 

• 

• Confirm that the 
system, 

subsystem, and 
component 
designs, derived 
fiomthe 
preliminary 
design, are of 
sufficient detail to 
allow for orderly 
hardware/ 
software design 
status assessment 
and smooth 
transition towards 
the manufacturing 
phase. 

• Same as the IDR, 
only serves as an 
additional check 
on the engine 
development 
progress. 

• Confirm that the 
system, 

subsystem, and 
component 
designs, derived 
from the 
preliminary 
design, are of 
sufficient detail to 
allow for orderly 
haidware/softwar 
e manufacturing, 
integration, and 
testing, and 
represent 
acceptable risk. 


Table 1: Milestone Reviews 
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Finally, the COBRA Project Manager decreed that all 
RIDs had to be closed prior to the successive review as 
part of the entrance criteria. All this collectively 
generated a scenario of programmatic disaster if the 
discrepancy process was not streamlined. 

In order to effectively conduct the high volume of 
reviews, they were separated into either primary 
(government-led) and secondary (contractor-led) 
reviews. The difference between primary and 
secondary reviews focused primarily on the scope of 
the review ajnd processes used to document and correct 
discrepancies. The scope of primary reviews was 
primarily on system or subsystem level design, while 
secondary reviews focused more on the component 
level. Primary reviews used a modified RID process to 
document and correct discrepancies, and the secondary 
reviews use a less formal Action Item process. 
Secondary reviews also did not require the convening 
of a review preboard or board. 

For a primary review, in addition to RIDs, Action Items 
and Comments were also be used to document 
discrepancies of less gravity. Action Items were 
provided to the contractor to evaluate for correction 
external to the RID process and were dispositioned, 
tracked and closed by the contractor with the 
concurrence of the initiator (thereby reducing the 
signature cycle from 9+ to 2). The criteria for 
classifying discrepancies as Action Items are: 

• Discrepancies that do not require NASA oversight 
to implement a corrective action and do not have a 
cost or schedule impact that must be supported by 
NASA (i.e., the corrective action is necessary but 
external to the current negotiated scope of work). 
An Action Item can have a cost or schedule impact 
if the contractor accepts that the corrective action is 
within the current scope of work. 


• Discrepancies that are not within the immediate 
scope of the review, but are relevant to be 
considered for the longer-term goals. 

Closure and tracking of RIDs were still controlled by 
the government, while Action Items were controlled by 
the JV with government insight into their status. 
Discrepancies classified as Comments are those that are 
considered to be of a non-critical nature and whose 
corrective action is left to the discretion of the 
Contractor. The closure of Comments is not tracked 
following its delivery to the contractor. 

Another practice that was implemented as part of the 
review process was the use of periodic “RID closure 
summits” that were used to assess the closure status of 
RIDs and Action Items leading up to the entry gate 
meeting of a particular review. This was useful in 
preventing a last-minute feeding frenzy of RID closures 
on the days before the entry gate meeting and also 
helped to ensure steady progress in the correction and 
. closure of all discrepancies. 

2.1.2 IPT Participation 

Another important avenue of providing insight to the 
contractor was the participation in the regular standing 
IPT meetings to status component development. To 
effectively support these meetings, programmatic and 
institutional government personnel would attend to help 
resolve any issues that might arise. This permitted 
regular involvement to assist in the identification and 
resolution of issues or anomalies, review analysis 
findings or their guiding assumptions, and provide a 
regular source of technical interchange. 

Also, in order to promote better communication 
between the customer and the contractor, the NASA 
COBRA Project Office structured its personnel in 
parallel to the JV organization. This is shown below in 
figure 1 [^]: 


JV NASA 
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2,13 Data Deliverables and OPRs 

Another source of customer insight external to the 
milestone reviews was the periodic submittal of data 
deliverables that reported the development progress and 
documented the results of analyses and trades. Each 
submitted document was written in accordance with the 
Data Requirements Description (DRD), which were 
collected in the Data Procurement Document (DPD). 
Each DRD was assigned to an Office of Primary 
Responsibility (OPR), who was a government person 
charged with the responsibility to ensure that the 
document submitted was 1) of satisfactory quality, 2) in 
compliance with the DRD, 3) submitted on time, and 4) 
showed steady progress in the development of the 
engine toward the project goals. 

During the course of the COBRA project, over 500 
documents were officially submitted to the government, 
many of them resubmittals or updates of previously- 
submitted documents. This heavy load of 
documentation was a significant strain on the OPRs, 
which generated an increased risk of losing or 
degrading the insight offered by the documents. It was 
also a burden on the contractor, who had to draft the 
documents in the first place. Finally, it was clear that a 
document that was not given sufficient review by the 
customer was a waste of time and money. 

The process for the preparation, delivery and review of 
the data deliverable documents was extensively (and 
repeatedly) revised over the course of the project, with 
the objective being to orchestrate the content and 
delivery frequency of the documents to where the OPRs 
were not overwhelmed. This problem can be avoided 
in future projects by careful selection and wording of 
the DRD at the beginning of the project, preferably 
during contract negotiations. 

2.2 The Design Cycle 

A design cycle is the interval between major engine- 
level milestone reviews. During this period, there 
should be one or more iterations of the engine system 
design to: 

• Update system-level requirements and verification 
criteria/plans, which were flowed down to the 
component level using the Dynamic Object 
Oriented Requirement System (DOORS) database. 
DOORS was also used for verification planning 
and compliance tracking. 

• Incorporate the latest component configurations 
and intra-engine interface definitions into the 
systems models using the Component Interface 
Control Records (CICR) database system. 

• Perform the required system level analyses (loads, 
power balance, FMEA, etc.) with the most current 


component configurations based on the CICR 
inventory. 

• Flow the system level analyses results to the 
components and subsequently assess component 
compliance with the system analyses. 

• Revise all drawings and intra-engihe interface 
definitions to reflect the updated analyses. 

The establishment of an effective design cycle requires 
the orchestration of the data flow and phasing to 
facilitate proper horizontal and vertical alignment of the 
engine design maturity at the end of the design cycle. 
Absence of a rigorous systems engineering process for 
regulating the design cycle will ensure that engine 
development follows the less-efficient “tossed salad” 
design cycle approach which is less likely to provide 
horizontal and vertical alignment of the engine design 
state at the successive engine-level milestone review. 

Proper vertical and horizontal integration requires that 
all teams (IPTs, SD&CI, PD&V, R&MA, PSA&I, 

MSE, ESIT, CCB, and perhaps RMT) work as an 
integrated team, orchestrated mostly by the Chief 
Engineer and/or SD&CI, through a design cycle. The 
engine development plan should explain what data is 
needed first and why, and then what is needed next, and 
so forth through the end of the design cycle. 

2.2. 1 Data Flow and Phasing 

SE team planned the data phasing used to accomplish a 
design cycle, including data outputs and inputs for 
design and analysis activities. The phased logic used 
took data outputs (analyses, design trades and drawings, 
etc) from a work item conducted earlier in the design 
cycle, and input this data into another work item that 
required a finite time to be completed during the design 
cycle. 

2.2.2 Horizontal Alignment 

Horizontal alignment of the engine system assures that 
all associated system documentation (i.e., requirements, 
interface definitions, power balance or loads model 
version, etc.) is consistent such that the design 
presented at the milestone is traceable to the system 
requirements and has been analyzed at the system level 
to show compliance with the system level requirements. 
This is to guarantee that there are no discontinuities in 
the data or design used in the engine design at the time 
of the milestone review. 

2.2.3 Vertical Alignment 

Proper orchestration of the vertical alignment of the 
engine development assures that all components at the 
time of a milestone engine review milestones are at a 
maturity level greater or equal to the engine milestone 
as indicated by the completion of component 
milestones. For example, at the time of the prototype 
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engine system IDR, all constituent components had at 
least to have successfully completed their component 
level IDR. 

2.3 Fusing SLI Strategic Goals (the *ilities) into 
the COBRA 

One thing that was made clear early and repeatedly in 
the COBRA project was that the engine had to do more 
than efficiently produce thrust - it had to be markedly 
safer, more reliable and more cost effective than any 
rocket engine before it. One important Lesson Learned 
that was emphasized was to make the engine safe, 
reliable and easy to maintain as key features of the 
initial design and avoid correcting safety issues by the 
application of labor-intensive and costly maintenance 
and operations “band-aids.” 

To accomplish this, both partners of the JV brought 
their own unique strengths to the table. In addition to a 
long heritage in the development of rocket engines, 
P&W also has even more experience in the 
development and deployment of highly reliable 
commercial and military turbine engines. While there 
is no direct relationship between liquid rocket engines 
and turbojets, there was an obvious benefit in utilizing 
some of the design approaches used in the turbine 
engines that would enhance the safety, reliability, and 
maintainability of the COBRA. At the same time, 
Aerojet had its own unique history of solid and liquid 
rocket engine development, most specifically in the 
area of combustion devices. In addition to a growing 
experience base in the development of channel- wall 
nozzles and combustion chambers, Aerojet would also 
be contributing its talents in the use of platelet injectors 
for the prebumer and main injector, which had a long 
history of trouble-free use on the AJlO-190 OMS 
engines on the Space Shuttle. 

However, to produce the COBRA to where it achieved 
the strategic program objectives would require more 
than a proven track record with demonstrated 
technologies, it would require the right development 
approach to make certain that “the ‘ilities” were given 
the right amount of up-front emphasis in the engine 
design and not shoe-homed in later as an afterthought. 

2.3.1 IPX Staffing and Empowerment 

To help ensure that enough consideration was given to 
the strategic objectives of the development project, the 
JV made sure that the Integrated Product Teams (IPTs) 
for all components had representatives from ESIT, 
especially the R&MA element. 

Each design cycle involved a review of the component 
failure modes, projected maintenance activities and the 
time and manpower required to accomplish it. Any 
change to a component design required consideration 


the change would have on adjacent components, the 
engine system, and the TPMs. It was emphasized that 
at a level of maturity that enabled a design-to-safety 
approach, the FMEA had to be maintained in a timely 
way to affect trades and planning for controlling safety- 
critical items via inspections. 

2.3.2 Decomposition & Allocation of Key 
Requirements to the Component Level 

An important facet of the systems engineering function 
is the decomposition, flow-down and traceability of 
requirements to the component-, and possibly subscale-, 
level. This can typically include requirements such as 
weight and cost. Specific to the COBRA development 
effort, this also included the unique decomposition and 
allocation of reliability and tum-around-time (TAT) 
requirements to the component level. The 
decomposition of these requirements to the component 
level would collectively achieve the project-critical 
system-level requirements. 

2.3.3 TPM Tracking 

TPMs are the key goals of the 2GRLV main propulsion 
system program explicitly defined as product metrics. 
Target TPMs for the COBRA FSD engine were defined 
early in the prototype engine development project after 
a careful examination of the PSRD and consideration of 
the competitive goals of the JV. TPMs for the 
prototype engine development project were then 
defined based on the FSD engine TPMs, and the level 
of achievement to be accomplished during prototype 
engine development to show the path to the FSD TPMs. 
The prototype engine TPMs became the key criteria by 
which success of the prototype development was 
determined and was reported on a monthly basis. 

TPMs monitored for the COBRA engine included: 

• Safety & Reliability 

• Weight (& ThrustAV eight) 

• Performance 

• Cost (Cost/Engine/Flight, DDT&E Cost) 

• Engine Life 

• Maintainability (overhaul interval, TAT, LRU or 
engine replacement time) 

In the event that a TPM was noncompliant with its 
allocated metric or indicated increased evidence of 
development risk, a risk item was initiated in the engine 
risk database for tracking and mitigation. A risk 
mitigation plan would be worked out that would be 
executed to bring the TPM into compliance with the 
2GRLV objectives. In some instances, this might 
involve trading of trading TPM allocations at the 
component level with components with surplus 
allocation margin. In other cases, it might require a 
redesign effort to resolve the noncompliance. 
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2.3.4 Trade Weighting 

In addition to the foundation laid by the work 
conducted under NRA8-27, innumerable trade studies 
were performed during the conceptual and preliminary 
design phases of the engine development. Any trade, 
which impacted more than one IPT was considered a 
system level trade. System level trades assured that the 
engine system was optimized, not necessarily to any 
one component. These trades identified engine 
characteristics such as the powerduct shape, pump 
orientation, and gimbal mount attach points. The final 
types of trades conducted were component trades. 

These trades were to performed ensure that all allocated 
requirements are met by all components, thus ensuring 
all system level requirements are met. 

The 2GRLV program TPMs were organized into four 
major groups which represent the major figures of merit 
to be used in the evaluation of the trade. In rank of 
highest weight, they were: 

• Safety & Reliability 

• Economics & Cost 

• Technical Performance 

• Risk Reduction. 

The Safety & Reliability figure of merit was further 
decomposed into Loss of Crew/Vehicle, and Launch 
Availability. The Economics/Cost figure of merit is 
broken down into Development Cost, Production Cost, 
Operations Cost, and Launch Cost. All of the 
objectives had corresponding engine attributes 
associated with them, each of which is given a 
numerical score. 

3. Summary 

Shortly before the engine-level milestone IDR in the 
summer of 2002, NASA announced that it would not 
exercise the contract option to continue development of 
the COBRA engine. This fate also befell the 
Rocketdyne RS-83 engine development project. The 
suspension of development efforts was not due to 
technical or programmatic deficiencies in either project, 
but was due to reorientation of SLI priorities to focus 
on LOX/kerosene booster engine development. With 


the limited program budget (and manpower), the 
LOX/LH2 development effort could not be continued in 
parallel and was suspended. 

As an epilogue, in the spring of 2003, the NASA Office 
of Aerospace Technology (OAT) awarded the COBRA 
project an award for ‘Turning Goals into Reality” in 
recognition of their accomplishments. The award 
statement reads as follows: 

COBRA - An example of technological innovation 
and exemplary teamwork 

Liquid oxygen/hydrogen single-prebumer-fuel-rich- 
staged-combustion engine scaleable fi-om 200k- 1000k 
Ibf with prototype design at 565klbf utilizing a GOX- 
driven boost pump, SSME pump technology, liquid- 
liquid prebumer, platelets, channel- wall nozzle, and 
health management providing a factor of 50 safety and 
10 life than current world benchmark. Developed with 
a strategy of insight and teamwork between 
NASA/MSFC and Pratt & Whitney/Aerojet to design a 
prototype with risk reduction of enabling technologies 
for a new generation propulsion system using Space 
Shuttle lessons lived and innovative business practices 
through rigorous risk management with strict adherence 
to Earned Value and Systems Engineering. 

It should be emphasized that this paper is not intended 
to describe the entire end-to-end systems engineering 
process that was utilized during the COBRA 
development effort, only those techniques that were 
developed by the JV and its NASA insight counterparts 
to help ensure that the resulting product was a 
demonstrably safe, reliable and cost-effective prototype 
engine that could be efficiently carried forward into the 
FSD effort. The development of these techniques was 
by no means instantaneous or painless, but in the end 
showed a high degree of synergy in orchestrating the 
efforts of so many talented personnel toward a common 
goal. 
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